1. Field of the Invention
The present invention relates to an input/output control apparatus, an input/output control system, and an input/output control method, which control shared use of input/output devices by more than one operating system (hereinafter referred to as “OS”).
2. Description of the Related Art
In a computer on which a single OS operates, software for controlling input/output devices (hereinafter referred to as “device drivers”) allows the OS itself and a program operating on the OS to access the input/output devices provided to the computer, and the device driver is the one installed into the OS as appropriate.
Here, the computer is provided with at least an input device (such as a keyboard) and an output device (such as a display device). The input device is used when inputting information into the OS from the outside of the computer. The output device is used when the OS outputs information from the computer to the outside of the computer.
The device driver registers, to the OS, information on the device to be controlled by the device driver itself, when the device driver is installed into the OS. An interrupt number for the device can be cited as an example of the information on such a device.
When information is inputted to the computer from the outside of the computer, firstly, an interrupt controller sends, to a CPU, an interrupt signal and an interrupt number.
Secondly, upon receipt of the interrupt signal, the CPU stops a process being performed at the time, and then calls a device driver corresponding to the interrupt number.
Thirdly, the device driver accesses the corresponding device, and then passes, to the OS, the information inputted through the device.
Furthermore, when outputting specific information, the OS specifies an appropriate output device in accordance with the content of the specific information.
Thereafter, the OS calls a device driver which has been registered in advance and which corresponds to the output device, and then causes the specific information to be outputted from the output device.
As described above, in a case where a single OS operates on a computer, by managing use of input/output devices, the OS can prevents an occurrence of a conflict situation in which programs operating on the OS access one of the input/output devices at the same time.
On the other hand, in recent years, an environment where multiple OSs can be simultaneously executed on a computer has been becoming prevalent.
As shown in FIG. 12, such an environment can be realized by a host system termed as a “virtual machine monitor (hereinafter referred to as a VMM)”. The VMM configures guest systems termed as “virtual machines (hereinafter referred to as VMs)”. Then, the VMM operates an OS on each of the VMs (for example, refer to the Patent document 1, the Non-patent document 1 and the Non-patent document 2).
One of conceivable examples of use of such an environment is that a “real-time OS (hereinafter referred to as an RTOS)” specialized in real-time processing, and a “general purpose OS (hereinafter referred to as a GPOS)” used for general purposes are simultaneously operated on a single computer.
Moreover, another example thereof is that each of multiple OSs provides a service specialized in the OS to a client by causing the multiple OSs to be operated on a single sever.
Under such an environment, limited hardware resources including input/output devices have to be shared by multiple OSs.
One of the roles of the VMM is to statically or dynamically allocate hardware resources to each of the OSs.
For example, the VMM dynamically passes the control right of the CPU to each of the OSs, and logically divides and allocates a main memory to each of the OSs, statically. Thereby, the VMM realizes a simultaneous execution of multiple OSs.
Furthermore, among VMMs, there is the one that realizes data communications between the multiple OSs being executed at the same time. In a typical method for executing the data communications, provided is a shared memory to which the multiple OSs can refer.
The VMM performs processes of managing the shared memory, or giving, to the OSs, the notification of writing to or reading from the shared memory.
Such a communications function between OSs is utilized not only when simple data communications are performed between the OSs, but also when hardware resources are shared by the multiple OSs.
For example, consider a case where multiple OSs on a computer provided with only one network interface communicate with the outside of the computer.
In this case, it is hardly conceivable to use a configuration in which each of the OSs independently includes a device driver of a network interface. This is because it is impossible to previously make a judgment on which one of the device drivers of the respective OSs is to be called for a hardware interrupt which occurs when receiving data.
Accordingly, it is necessary that a certain OS becomes only one holder of the device driver, and thereby that the OS being the holder of the device driver be in charge of transferring and receiving data, and assigning the data to each of the OSs.
When hardware resources are shared and utilized as in the case described above, the aforementioned communications function between the OSs becomes a requirement.
Here, consider a device which is to be exclusively occupied by a specific OS at an arbitrary time under a multiple OSs environment realized by a VMM.
As an example of such a device, a human interface device (hereinafter referred to as an “HID”) can be cited. As examples of the HID, a keyboard as an input device, a display device as an output device and the like can be cited.
These devices need to be exclusively occupied by the OS, which is being used by a user.
For example, while the user is using a certain program, the result of an input by the user from a keyboard needs to be basically inputted to the certain program, and the result of an output from the certain program needs to be displayed on the display device. For this purpose, the result of the input from the keyboard has to be passed to the OS on which the certain program operates. Likewise, the result of the output from the OS needs to be displayed on the display device.
Moreover, the fact that a user is using a certain OS does not necessary mean that the OS being used by the user also controls the CPU.
Even though the OS is being used by the user, the VMM may switch contexts between OSs. Then, the VMM may assign the CPU to another OS, or execute a process for the VMM itself.
The VMM can grasp which OS controls the CPU at an arbitrary time since the VMM manages the assignment of the CPU. The VMM, however, cannot grasp which OS is being used by the user at an arbitrary time.
Accordingly, for example, in a case where an input of data from the keyboard causes an interrupt, the VMM cannot recognize which OS the interrupt is caused for.
For example, when a network interface is shared by OSs, received data can be assigned after a certain OS receives the data. This can be possible because an IP address, a port number or the like is added to the received data for identifying which OS the data is inputted for.
It is, however, difficult to perform the same processing on data which is inputted from a keyboard.
Likewise, a problem occurs when data is outputted to the display device.
If all of the OSs individually hold the respective display drivers, and output data at their own choices, a conflict for the display device occurs, as a matter of course.
Moreover, even in a case where data to be outputted to a certain OS is aggregated, the correct output result cannot be displayed for the user without recognizing which OS is to output the data at the time.
In the case of the multiple OSs environment described in the Patent document 1, any specific function is not provided in order to solve the problems described above.
This is because the Patent document 1 assumes a simultaneous execution environment of an RTOS and a GPOS. That is, an assumption is made that the GPOS always occupies an HID.
On the other hand, in the multiple OSs environment described in the Non-patent document 1 or the Non-Patent document 2, as shown in FIG. 13, the sharing of an HID is achieved by providing one host OS to the environment, and then by causing a Graphical User Interface (GUI) server of the host OS to process inputs and outputs to the HID for all the other guest OSs.
To be more precise, only the host OS holds the device driver (HID DD) of the HID, and the device driver is allowed to process only the inputs and outputs from the GUI server of the host OS.
The GUI server of the host OS generates a window for each of the guest OSs other than the host OS, and outputs, on the window, the result of output which is received from a GUI server of the guest OS through communications between OS by using the VMM.
Furthermore, in a case where the window is active, the result of an input from the input device is passed to the GUI server of the corresponding guest OS through the communications between the OSs.
There are, however, problems in such a solution by means of GUI servers.
The first problem is that contexts need to be switched between OSs very often since all of the GUI client applications of the respective OSs perform input and output processing separately.
Under the multiple OSs environment, it takes a long time to perform processes for saving and restoring contexts when the contexts are switched between the OSs. In particular, context switching becomes a large bottleneck in output processing to a display device since a processing speed is important in the output processing.
Moreover, in an environment where a power saving processing is absolutely required as in the case of a mobile terminal, context switching also becomes a large factor causing an increase of electricity consumption.
The second problem is that the solution largely depends on platforms or applications of each of the OSs.
In order to realize such inputs and outputs between the GUI servers, both of the GUI servers of the host OS and each guest OS need to support functions for the inputs and outputs therebetween.
Moreover, particularly in a case where environments, in each of which a GUI server operates, are significantly different from one another, communications between the GUI servers require conversion of data in the application level.
The third problem is a security risk associated with the fact that all of the inputs and outputs processing are handled by the GUI servers.
Since a GUI server is an “unprivileged process (user authorization)”, its tamper resistance is weak in comparison with an OS which is a “privileged process (kernel authorization)”.
In a case where the GUI server is tampered with, the input and output of the OS may be inappropriately processed. This may causes an event in which an input result is passed to a wrong input destination, or in which an output result of the OS which is not supposed to be displayed is displayed.
Furthermore, in the switching of an OS occupying the HID to another, for the purpose of improving usability, various switching patterns need to be considered.
Moreover, as to each of the switching patterns, it is necessary to consider provision of switching methods, prevention of an unauthorized switching and an unauthorized occupation of the HID and the like.
The following cases are conceivable as examples of the switching patterns.                In the case where a specific program is started on a specific OS;        In the case where a switching button provided to a keyboard or the like is pressed;        In the case where an abnormality occurs on the OS which occupies the HID; and        In the case where a specific program is forcibly started from the outside of the computer for the purpose of debugging or the like.        
Moreover, the following matters are conceivable as examples of matters to be considered at the time of switching OSs.                Prevention of an unauthorized occupation of the HID by a specific OS or a specific program;        Prevention of repeated switching which may reduce usability; and        Prevention of switching in a case where a program with a high priority is used.<Patent document 1> US 2004/0205755<Non-Patent document 1> “Xen and the Art of Virtualization” In Proc. of Symposium on operating systems Principles (SOSP) 2003 (http://www.Cl.cam.ac.uk/Res earch/SRG/netos/papers/2003-xensosp.pdf)<Non-patent document 2> “A 600MIPS 120 mW 70 μA Leakage Triple-CPU Mobile Application Processor Chip” In Proc. of IEEE International Solid-State Circuits Conference (ISSCC) 2005        